Why?

TL;DR Spec-compliant differences in browser implementations of the Date API resulted in different variations of the timezone name on Android and iOS.

Publication Timestamp

The publication timestamp at the top of articles looks something like this:

Tue 24 May 2022 11.47 (<current timezone name>)

For apps this timestamp and the corresponding timezone are in the user's local time, and so both the datetime and the timezone name can have a large number of values. We calculate this on the user's device rather than setting it on the server. This differs from dotcom, which I believe uses a handful of timezones based on edition, calculated on the server.

The Bug

We've had a long-standing issue where the publication timestamp at the top of AR articles has sometimes shown the full timezone name, rather than an abbreviation. This means users see "British Summer Time" rather than "BST". This is unusual enough that it's previously been reported as a bug.

It turns out that "sometimes" is actually platform specific. Android users are seeing the full timezone, iOS users are seeing the abbreviation. It also transpires that if you view AR in a normal browser, Safari shows the abbreviated timezone but Firefox shows the long-form version. This suggests that Chrome (Android webviews) and Firefox are displaying timezones one way, and Safari (iOS webviews) are displaying them another.

What's Going On?

For the web publication date, AR has been using JavaScript's Date.toTimeString() method and a regex to retrieve the timezone name. The JavaScript Date API is capable of generating timezone names, but doesn't expose them directly, so you have to extract them from one of the strings produced by other methods (this is awkward).

It turns out that Safari's implementation of this method produces a string that looks like this:

18:33:09 GMT+0100 (BST)

whereas Chrome/Firefox produce one that looks like this:

18:33:09 GMT+0100 (British Summer Time)

As far as I can tell, this isn't due to a bug but actually an ambiguity in the spec. The spec for that method and the spec for the timezone name state that this name is "implementation-defined". So Chrome, Safari and Firefox have decided to implement this differently 🤷.

The Fix

Thanks to @DavidLawes (⭐️) we have an alternate function called localTimeZoneAbbr that instead uses Date.toLocaleString and its ability to explicitly specify a "short" timezone name. So I've switched over to using that 🙂.

I've also dropped the enclosing braces, so the whole timestamp should now appear in a format identical to dotcom's. See the screenshots below.

Node also implements the long-form version, likely because it has the same V8 engine as Chrome. This meant that our tests were previously set up to expect this - I've now updated them to expect the short-form version.

Changes

• Switched formatLocal over to use localTimeZoneAbbr
• Removed now-unused localTimeZone
• Updated tests to expect short-form timezone

Screenshots

Browser	Before	After
Safari/iOS
Chrome/Firefox/Android